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1 Introduction 

MPLS has the potential to consolidate service provider networks and services, in 
particular ATM, over a single common core infrastructure. At the last two meetings of the 
ATM Forum, the AIC group agreed to produce a specification for ATM services over 
MPLS. One aspects of this work is to define an MPLS protocol to encapsulate ATM cells 
and AAL 5 protocol data units as discussed in the companion contribution [1]. 

The purpose of this contribution is to discuss the use of PNNI as the control protocol for 
providing ATM services over MPLS. The contribution is structured as follows: Section 2 
presents the architecture and the transport requirements for multi-service, including ATM 
services, over MPLS. Section 3 describes the role of PNNI over MPLS networks. Section 
4 discusses the use of PNNI signalling to establish MPLS label switched paths between 
ATM-MPLS interworking units. Finally, Section 5 proposes protocol stacks for 
transporting PNNI messages over MPLS networks. 



2 Architecture and requirements 
2.1 ATM-MPLS Reference Model 

ATM over MPLS reference model is shown in Figure 1 . ATM-MPLS interworking units 
(IWG units) are attached to an MPLS network. MPLS label switched paths (LSPs) called 
"transport LSPs" connect a pair of IWG units. One of the IWG units is the source of data 
flowing in a transport LSP and the other the sink. Several "Interworking LSPs" (I-LSPs) 
can be nested inside one transport LSP. Each I-LSP corresponds to an ATM virtual path 
connection (VPC) or virtual channel connection (VCC). One of the main roles of an 
ATM-MPLS IWG unit is to map MPLS I-LSPs to the corresponding ATM connections 
and vice versa. 




ATM 
PNNI 
node 



Figure 1 - Reference model 
2.2 Data Transfer protocol stacks 

The MPLS side of an IWG unit consists of the following protocol layers: Above the 
physical layer runs a link layer protocol, for example PPP over Sonet/SDH as defined in 
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RFC 2615 [2]. Above the link layer there is MPLS label stack processing defined in RFC 
3032 [3]. Between two IWG units the "Multi-service over MPLS" (MS/MPLS) protocol 
runs. The ATM Forum AIC group currently is addressing the ATM aspects of this 
protocol 

The ATM side of an IWG unit consists of the physical and ATM layers. AAL 5 
terminates at the IWG when AAL 5 PDUs will be transmitted over the MPLS network 
rather than ATM cells. More details on the transport methods over MPLS can be found in 
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Figure 2 - Data transfer protocol stacks 



2.3 Multi-service over MPLS frame format 

The frame format for Multi-service over MPLS (MS/MPLS) is shown in Figure 3. It 
consists of the link layer protocol header followed by MPLS label stack defined in [3] and 
MS/MPLS service specific header. MS/MPLS specific header is a variable length header 
specific to a technology (for example, ATM or frame relay). ATM over MPLS specific 
header is defined in [1]. The payload field contains user or network data. 
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Link layer protocol control information 

MPLS transport LSP label(s) 

MPLS Interworking LSP label 

ATM (and in general Multi-service) 
over MPLS specific header 

Payload 

Link layer protocol trailer 

Figure 3 - Multi-service over MPLS frame format 

2.4 ATM over MPLS transport requirements and transport modes 

The contribution on ATM encapsulation over MPLS [1] identifies the following ATM 
over MPLS transport requirements: 

1 . Support of ATM Virtual path and virtual channel connections (VPC and VCC) 

2. Support all AAL types and cell types (user and OAM cells) 

3. Support of existing ATM traffic and QoS capabilities 

4. Ability to transport a single cell in a MS/MPLS frame 

5. Ability to transport concatenated cells in a MS/MPLS frame 

6. Ability to transport a complete or fragmented AAL 5 frames in a MS/MPLS 
frame 

Transport of a single cell encapsulated in a MS/MPLS frame is the only mandatory 
transport mode. Transport of AAL 5 PDUs and concatenated cells are optional transport 
modes. 

3 PNNI over MPLS networks 
3.1 Role of PNNI 
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From PNNI perspective, MPLS network and transport LSPs can be considered as an 
abstraction of a PNNI physical link established between two PNNI nodes. Figure 4 
captures this view. In an ATM over MPLS environment, the role of PNNI routing 
protocols is the same as in a traditional ATM PNNI network. The role of PNNI signalling 
is to establish MPLS I-LSPs between IWG units during AM VCC or VPC establishment 
and to perform other signalling functions defined in PNNI specification. More on the 
signalling role of PNNI is addressed later in the contribution. The routing aspects of 
PNNI over MPLS network will be addressed in a future contribution 
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Figure 4 - PNNI over MPLS network 



3.2 Relationship between ATM connection and MPLS LSP 

ATM connections (VPC and VCC) are usually considered to be bi-directional entities 
mainly because of the way they are created and identified. A single identifier (a VPI or a 
VCI respectively) refers to the two directions of a VPC or VCC and ATM signalling 
establishes the two directions simultaneously with the same signalling message flows. 
But in general each direction of a VPC or VCC may have different traffic and QoS 
characteristics and PNNI, from a resource management perspective, treats each direction 
separately and independently. MPLS LSPs, on the other hand, are uni-directional entities 
from different perspectives: Traffic and QoS engineering, data flow and from the way 
they are created and identified (labeled). 

ATM over MPLS requires to "interwork" ATM VPC or VCC with MPLS LSP. An ATM 
VCC is a sequence of virtual channel links (VCL) and an ATM VPC is a sequence of 
virtual path links (VPL). During the creation of a VCC or VPC a pair of I-LSPs will have 
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to be established between two IWG units. Each I-LSP will carry traffic in one direction 
only. 

Each I-LSP is established in a different transport LSP such that the flow of data of an I- 
LSP is the same as the flow of data allowed in the corresponding Transport LSP. Note the 
pair of transport LSPs used to carry VCC or VPC traffic in opposite directions are 
establishment on the same physical interface. 

Figure 5 illustrates the relationship between transport LSP, I-LSP and ATM VCC or 
VPC. The terminology of PNNI signalling is adopted: The preceding IWG unit is the 
IWG unit initiating the establishment of an ATM VCC or VPC. The succeeding IWG unit 
is the IWG unit receiving a request to establish an ATM VCC or VPC. The forward 
(transport or interworking) LSP is the LSP carrying the traffic from the preceding IWG 
unit to the succeeding IWG units. The backward LSP is the LSP carrying the traffic in the 
opposite direction. 




(a) ATM VCC and MPLS I-LSP 
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(b) ATM VPC and MPLS I-LSP 
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Figure 5 - ATM VCC and VPC and MPLS LSP 

PNNI physical links have their own signalling and routing control channels. The default 
signalling channel is in VPI=0 and VCI=5 and the default routing control channel is in 
VPI=0 and VCI=18. Likewise each transport LSP used as a PNNI physical link will have 
its own nested LSP one for carrying PNNI signalling messages between two IWG units 
and the other for the routing messages. The signalling channel of a transport LSP is used 
to create I-LSP within the transport LSP. Figure 6 shows the different LSPs (I-LSP, 
signalling and routing LSP) nested in a pair of forward and backward transport LSPs. 




Figure 6 - Transport LSPs and their different nested LSPs 

3.3 PNNI over MPLS specific requirements 

PNNI Signalling over MPLS will be used for: 

- Establishing I-LSPs between ATM-MPLS IWG units 

- Transporting I-LSP labels between IWG-units 

- Selecting the transport mode (single cell, concatenated cells, or AAL 5 
frames) 

- Negotiating of the maximum number of concatenated cells 

- Negotiating of the presence of the VCI in ATM over MPLS specific header 

PNNI routing aspects over MPLS networks will be addressed in a future contribution. 
Now it is sufficient to say that implementations will need to assign a PNNI port identifier 
for each transport LSP used as a PNNI physical link. PNNI port identifiers are used in 
different PNNI protocols. 
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4 PNNI signalling over MPLS network 
4.1 Signalling of various parameters 

Several new parameters have to be signalled between two IWG units during I-LSPs 
establishment. They are identified in the following subsections. Other parameters may be 
added in the future depending on the needs. For some of the parameters, negotiation 
procedures have to be defined. The details will be provided in a future contribution. 

4.1.1 LSP label values and transport LSP local port identifier 

The following LSP identifiers have to be exchanged between the two IWG units: 

- Forward I-LSP label value 

- Backward I-LSP label value 

- Port identifier assigned to the backward transport LSP by the preceding IWG unit. 
The role of this identifier will become clear in the subsection on I-LSP 
establishment procedures. 

4.1.2 Transport mode selection 

The following transport modes are allowed (see [1] for details): 

- Single cell transport: When this mode is selected a single user cell is encapsulated 
an ATM over MPLS frame. This transport mode is applicable to VCC and VPC 
and is the only mandatory transport mode to support by ATM-MPLS IWG units. 

- Concatenated cell transport: When this mode is selected multiple user cells may be 
encapsulated in an ATM over MPLS frame. This transport mode is applicable to 
VCC and VPC. 

- Complete re-assembled AAL 5 PDU: When this mode is selected a complete AAL 
5 PDU consisting of the payload, Pad and control information will be encapsulated 
in an ATM over MPLS frame. This mode implies that an IWG unit will have to re- 
assemble cells belonging to an AAL 5 PDU. 

- Segmented AAL 5 PDU transport: When this mode is selected an incomplete AAL 
5 PDU may be encapsulated in an ATM over MPLS frame. There are at least two 
reasons to send incomplete AAL 5 PDUs: The first one is when an OAM cell is 
received and the second one is when an AAL 5 PDU is too long for transmission 
over the MPLS network. 

The transport mode has to be selected between the two IWG units for each I-LSP. Only 
single cell transport mode is mandatory, the other modes are optional. Therefore 
negotiation procedure with fall back to single cell transport mode will have to be defined. 

4.1.3 Presence of the VCI field 

The presence of the VCI field in ATM over MPLS specific header has to be negotiated 
for each I-LSP. Several choices are possible (for example: VCI is always present or never 
present). 

The different choices will be defined and details provided in a future contribution. 
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4.1.4 Maximum number of concatenated cells 

With concatenated cell transport, there is a need to negotiate the maximum number of 
cells that can be encapsulated in an ATM over MPLS frame. This negotiation has to be 
done for each I-LSP. 

Note AAL 5 PDU length can be obtained from the AAL information element. 

4.1.5 Usefulness of PNNI information elements for I-LSP establishment 

Most of PNNI information elements carried in the SETUP message provide important 
information about the characteristics and other attributes of the I-LSP to be established 
between the two ATM-MPLS IWG units: 

- AAL parameters: This information element identifies the AAL protocol that 
will be used. In particular if it is AAL 5, the IWG units can determine whether 
to operate in AAL 5 frame transport mode or cell transport mode. In the case of 
AAL 5 this information element provides also the maximum length of AAL 5 
frame payload. 

- ABR additional parameters, ABR setup parameters, Alternative ATM traffic 
descriptor, ATM traffic descriptor, End-to-end transit delay, Extended QoS 
parameters, Minimum acceptable ATM traffic descriptor and QoS parameter: 
These information elements contain traffic and QoS characteristics of the ATM 
VCC or VPC to setup. The IWG units will have to use them to establish I-LSP 
with the right traffic and QoS characteristics. 

- Broadband bearer capability: This information element identifies ATM traffic 
capability (for example: CBR or VBR) and whether the request is to establish a 
user VCC or VPC. 

- Calling and called party soft PVPC and PVCC indicates that the connection is a 
soft PVPC or PVCC rather than SVC. 

- Connection identifier: This information element includes the VCI to be 
optionally inserted in ATM over MPLS specific header. It provides also the 
VPI and information to the IWG units on associated vs. non-associated 
signalling. 

4.2 Outline of I-LSP establishment procedures between two IWF units 

1 . After receiving a request from one of its preceding PNNI node to establish a VCC or 
VPC, a preceding IWG unit initiates the establishment of a pair of I-LSPs between 
itself and a succeeding IWG unit. Figure 7 shows PNNI signalling message flows for 
the reference model of Figure 6. 
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2. A preceding IWG unit initiates the establishment of a pair of I-LSPs by sending a 
SETUP message to a succeeding IWG unit and by following the procedures of PNNI 
Section 6.5.2.about call/connection establishment relevant to a preceding PNNI node. 
In addition to the mandatory and optional information elements required to establish 
an ATM connection, the SETUP message shall contain some of the new information 
identified in Section 4.1 necessary to establish the pair of I-LSPs between the two 
IWG units. 

3. In the SETUP message, the preceding IWG unit shall contain the following additional 
information: The I-LSP backward label value and PNNI port identifier of the 
backward transport LSP to identify the transport LSP where the backward I-LSP will 
be established. In addition, it may provide other information such as the transport 
mode for each LSP, the presence of the VCI field and the maximum number of 
concatenated cells if it requests concatenated cell transport mode. 

4. The selection by the preceding IWG of the backward transport LSP requires that it 
performs CAC on that LSP in order to ensure that sufficient resources are available to 
satisfy the traffic and QoS requirements of the VCC or VPC being established. The 
backward transport LSP corresponds in PNNI to the incoming direction of a link. The 
state of the incoming direction of a PNNI link is obtained periodically from the node 
at the other end of the link. Between two updates, the preceding IWG can keep track 
of the backward transport LSP resources consumed so far. 

5. After receiving a SETUP message, the succeeding IWG unit follows the procedure of 
PNNI Section 6.5.2 applicable to a PNNI succeeding node. In addition, in the first 
positive reply message with global significance (ALERTING or CONNECT message) 
the succeeding IWG unit shall include the following new information: The forward I- 
LSP label value. In addition, it may provide other information such as the transport 
mode for each LSP, the presence of the VCI field and the maximum number of 
concatenated cells, if concatenated cell transport mode is selected. Negotiation 
procedures will be provided in a future contribution. 

6. The pair of I-LSPs are established between the two IWG units after the preceding 
IWG unit has received a CONNECT message from the succeeding IWG unit. 

7. The signalling messages sent by the preceding IWG unit are carried in the signalling 
LSP of the forward transport LSP. Similarly, the signalling messages sent by the 
succeeding IWG unit are carried in the signalling LSP of the backward transport LSP. 
The call reference encoded in PNNI signalling messages allows the IWG units to 
correlate, as belonging to the same call, the various messages sent and received in the 
backward and forward transport LSPs. 

8. To establish a parallel with MPLS architecture defined in RFC 3031 [4], the label 
assignment for the forward I-LSP corresponds to "downstream-on-demand" 
assignment" where the downstream label switching router (LSR) is the succeeding 
IWG unit. The preceding IWG unit corresponds to an upstream LSR requesting a 
label from the downstream LSR/succeeding IWG unit. For the forward I-LSP the 
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preceding IWG unit corresponds to the Ru LSR and the succeeding IWG unit to the 
Rd used in [4]. 

9. For the backward path the label assignment method roughly corresponds to 
"unsolicited downstream" label distribution of [4] since the succeeding IWG unit has 
not requested explicitly a label from the preceding IWG unit. The choice of this 
allocation method is caused by the way PNNI signalling establishes the two directions 
of a VCC or VPC and the need to avoid sending separate SETUP messages for each I- 
LSP. For the backward I-LSP, the succeeding IWG unit corresponds to an upstream or 
Ru LSR and the preceding IWG unit to a downstream or Ru LSR. 
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backward Transport LSP Port Id, 
other parameters for the forward 
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Setup(...) 


Alerting or 
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Alerting/Connect (...Forward I-LSP 
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^ Connect(...) 


< 
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Figure 7 - Forward and backward I-LSPs establishment 



4.3 Carriage of LSP parameters 

PNNI Generic Application Transport (GAT) capability is a suitable mechanism to 
transport PNNI information required to establish I-LSPs between two IWG units. GAT 
information element may be included in the SETUP, ALERTING and CONNECT 
message. GAT procedures specific to ATM over MPLS will have to be defined. 

GAT information element is shown in Figure 8. The required enhancements to the GAT 
IE are as follows: A new application type (octet 5) and Application-specific information 
(octet 6 to 512) have to be defined. 
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PNNI GAT information elements first four octets 



Application type 
New type: 0000 0101 (ATM over MPLS) 



Application-specific information 

Carriage of the forward and backward I-LSP labels 
and other parameters that need to be exchanged 
between the two interworking units 



Octet 



lto4 



6 to 512 



Figure 8 - Enhancements to GAT information element 

For ATM over MPLS GAT IE application-specific field will carry the different 
parameters discussed in subsection 4.1. A general layout is shown in Figure 9. The details 
will be provided in a future contribution. 



I-LSP forward or backward label value 



Forward I-LSP Parameters 



Octets 6 
to 512 of 
GAT IE 



Backward I-LSP Parameters 



Figure 9 - GAT IE application-specific field 
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5 Transport of PNNI messages 

Figure 10 shows PNNI protocol stacks over ATM and the proposed stacks for PNNI over 
MPLS. As shown in Figure 10 (b) above the physical layer, the link layer protocol and 
MPLS label stack processing appear followed by the protocol for ATM encapsulation 
over MPLS with frame transport only. 

It is proposed to keep SSCF at the UNI and SSCOP for PNNI signalling protocol and to 
have PNNI routing protocols run above ATM encapsulation over MPLS protocol defined 
in [1] with frame transport. There is no need to use AAL 5 for PNNI transport over 
MPLS. 
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a) PNNI over ATM transport 
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b) Proposed PNNI over MPLS transport 



Figure 10 - PNNI protocol stacks 

The frame format for PNNI message encapsulation in ATM over MPLS frames is shown 
in Figure 11. It is proposed to use the header format for AAL 5 PDU transport defined in 
[1] but without using the rightmost two bits assigned to CLP and EFCI and be setting 
them to 0. 
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MPLS Interworking LSP label (4 octets) 



VCIP 


Mode 


RES 


FRAG 


0 


yes/no 


frame 







VCI (optional) 



Payload = PNNI complete or 
segmented message 



Figure 11 - Frame format for PNNI messages 



6 Motion 

It is proposed to initiate work on PNNI for ATM services over MPLS networks based on 
Sections 2, 3, 4 and 5 of this contribution. 
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1 SD Tracking 



1.1 SD Entrance Criteria 



BEFORE starting Detail Design, ensure that: 


Yes 


No 


N/A 


FS is available to all developers who need it when applicable 


X 






Functionality/Interface input from other related features is available 




X 





1.2 SD Exit Criteria 



BEFORE declaring Detail Design done, ensure that: 


Yes 


No 


N/A 


Detail design covers all functionality outlined in the FS 








SD was reviewed with key developers 








Project Plan was revised and updated 








SD was updated from the review and released 








SD review minutes and closed action items are filed 
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2 Introduction 



This document describes the detailed design for the CDN Passport MS3/CE ATM 
Networking feature. 

2.1 Terminology 

ATM : Asynchronous Transfer Mode. ATM is a technology that provides access to a 
network by multiplexing user information into fixed-length units called cells. ATM forms 
the basis for broadband networks. 

ATM virtual link : Refers to a link from one ATM node to another in an ATM topology. 
CoS : Class of Service 



CPE : Customer Premises Equipment 

DPRS : Dynamic Packet Routing System. DPRS is a connectionless routing system for 
delay-sensitive and high-throughput variable bit rate traffic. DPRS carries data traffic such 
as frame relay and all DPN-100 services such as X.25. 

DTL : Designated Transit List. A list of node and link identifiers that completely specify a 
path across a single PNNI peer group. Link identifiers are optional. 

FP: Function Processor. An FP is a type of processor card that supports physical interface 
connections to subscriber lines and network trunks. It is optimized to support the software 
that performs the real-time functions associated with the forwarding and routing of 
frames. Different types of FPs support different types of physical interfaces, such as DS1, 
El , V.35, and V. 1 1 access and trunks. 

IISP : Interim Inter-Switch Signaling Protocol. ISP provides interconnection between 
Passport switches as well as interconnection between Passport and non-Passport switches 
(Nortel Networks- family switches and switches from other vendors). 

IP: Internet Protocol. IP is a protocol suite operating within the Internet as defined by the 
requests for comment (RFC). This may also refer to the network-layer (level 3) of this 
protocol stack; the layer concerned with routing datagrams from network to network. 

LSP: Label Switched Path 

L-LSP : Label inferred Label Switched Path 
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MPLS : Multi Protocol Label Switching.MPLS is a label-swapping, networking 
technology that forwards packet traffic over multiple, underlying layer-2 media. This 
technology integrates layer-2 switching and layer-3 routing by linking the layer-2 
infrastructure with layer-3 routing characteristics. Layer-3 routing occurs at the edge of 
the network, and layer-2 switching takes over in the MPLS network core. 

MPLS Domain : A contiguous set of nodes which operate MPLS routing and forwarding 
and which are also in one Routing or Administrative Domain. 

MPLS transport media : Refers to Label Switched Paths across an MPLS Domain which 
carry data from one end to the other. 

OPC : Optera Packet Core. Optera Packet Core. OPC is an IP router and MPLS core 
switching system operating in the TeraBits range. It is a central part of Nortel Networks' 
Unified Networks solution known as OPS (Optera Packet Solution). OPC provides a high- 
speed optical back bone, and it is aimed at a service provider and carrier market. 

Overlay model : A means of transporting one protocol over another where the two 
protocols use separate address, topology and connection management. 

PNNI : Private Network to Network Interface. PNNI is an ATM routing and signaling 
protocol that permits dynamic routing and networking. 

POS : Packet Over Sonet 

PPP : Point to Point Protocol 

QoS : Quality of Service. QoS is a series of service classes that reflect the traffic 
importance and urgency over a connection. For ATM networks and services, QOS classes 
are defined by the ATM Forum for UNI 3.0/3.1 (numerical designations 0 through 4) and 
for UNI 4.0 (UBR, CBR, rtVBR, nrtVBR) which have direct correspondence. Passport 
also defines a set of corresponding ATM QOS classes (UBR, CBR, VBR, CO, CNLS). For 
IP traffic over the VNS outbound media, Qos is defined at the inbound protocol port level, 
and implemented by VNS. 

Topology : The geometric physical or electrical configuration describing a local 
communication network — the shape or arrangement of the system. 

Tunnel: A secure, virtual point-to-point link that connects two points and transfers data 
from one point to the other. This data is not modified by the intervening nodes. 

UNI : User Network Interface. UNI can either be the frame relay service is provided 
through a standard interface between the user device and the network, or an interface 
between ATM user equipment and ATM network equipment. 

VCC : Virtual Channel Connection. VCC is a concatenation of virtual channel links that 
extends between two points where the ATM adaptation layer is accessed. 
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VC : Virtual Circuit. A VC is a connection between two devices that acts as though it's a 
direct connection even though it may physically be circuitous. The term is used most 
frequently to describe connections between two hosts in a packet-switching network. In 
this case, the two hosts can communicate as though they have a dedicated connection even 
though the packets might actually travel very different routes before arriving at their 
destination. An X.25 connection is an example of a virtual circuit. VCs can be either 
permanent (called PVCs) or temporary (called SVCs). 

VP : Virtual Path. In frame relay, a VP is the equivalent of a physical connection to a 
destination address using shared facilities. VPs can be permanent (PVP) or switched 
(SVP). The VP is anchored in the function processors that are connected to the end user 
devices. In ATM networking, a VP is a unidirectional transport of ATM cells belonging to 
virtual channels that are associated by a common identifier value called VPI. 

2.2 System overview 

ATM networking consists of a centralized ATM routing process on the CP and ATM 
Logical Port and Networking API processes on the FPs. Each ATM signaling instance 
maintains both a Logical Port process and a Networking API process. This overall system 
architecture is unchanged by the introduction of ATM Networking over MPLS and is 
illustrated in Figure 1. For a complete description of the ATM Networking, please refer to 
[1] MD-1997.0324, "Passport ATM Networking Phase-2", SD, Darren Newell et al, 
July 1999, Nortel Networks.. However, enhancements to LGP and ATM Core are 
required for ATM Networking over MPLS. 

Figure 1 High Level Architecture 
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In order to support ATM Networking over MPLS: 

• ATM Core is enhanced to provide: 

a. provide a new functional API interface to allow the passing of MPLS label data to 
and from ATM networking 

• LGP is enhanced to: 

a. store MPLS label data provided by ATM core 

b. store MPLS label data received in the GIT IE of a SETUP or CONNECT PDU 

c. interface with ATM Core to pass and receive MPLS label data 

d. support a new MPLS label identifier GIT information element. 

2.2.1 Design Strategy and Objectives 

The following three development considerations were the main objectives in the Passport 
implementation of ATM Networking over MPLS: 

• ensure that ATM Networking does not need to have any detailed knowledge of the 
MPLS data information being passed to and from ATM Core. In fact, from an ATM 
Networking point of view, this data need not even be MPLS related. 

• not require any code specific for IISP or PNNI. Keep the code as simple and generic as 
possible. 

• robustness and extensibility to subsequent ATM Networking over MPLS feature 
development. 
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3 Overall description 



3.1 Generic Identifier Transport Information Element 

Figure 2 GIT Information Element Format describes the format of the GIT IE 
containing the MPLS service label data which will be contained within the SETUP and 
CONNECT PDUs. This is described in more detail in [2] MD-2000.0422, "CDN 
Passport MS3/Capacity Evolution ATM Networking", FS, Andrew Laverance et al, 
Oct 2000,Nortel Networks- 



Figure 2 GIT Information Element Format 
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Length of Generic identifier transport information element contents (continued) 
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1 
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Identifier Value 
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Identifier Value 
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3.2 



System architecture 



3.2.1 



ATM Core Interface 



Figure 3 on page 16 descirbes the interface between ATM networking and ATM core in 
terms of interaction between data types. 

Figure 3 Overview of the MPLS ATM Networking interface to ATM core 



r 



ATM NETWORKING 
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remo 
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c 
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getXportDataSize 
getXportData 
setXportData 
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3.2.2 



ATM Call Control 



Figure 4 on page 17 shows the components involved in the ATM Call Control, their 
relationship and which components need to be modified by this feature. 

Figure 4 FP Call Control Architecture 



Link Side 



Network Side 



FP 
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DME 
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CP 
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backplane 
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3.3 Information flow 

3.3.1 Overview 

Figure 5 on page 18 illustrates the ATM Networking message and method sequence in 
creating on-demand connections over MPLS. 

Figure 5 ATM signaling of on-demand connections over MPLS 
ATM Interface (Calling Party Side) ATM Interface (Called Party Side) 

ATM Sig Atm Core Atm Sig AtmCore 



Setup 



Reserve Bw 

H 

Connection 



(jreate 2 

Outgoing Setup (Incl. CG end MPLS service label assign.) 



Reserve Bw 1 



Connection C 
Setup 3 



eate 



Incomini | Connect (Incl. CD end MPLS service label assign.) 



Connection 
Configure 

Enable 4 



Connect 3 



C reate 5 





Connect 


Configure 




Enable 4 





Note: 

1 MPLS service label assignment provided to ATM Networking along 
with MPLS transport LSP selection. 

2 Only If VPCt/VCI assignment authority. 

3 MPLS service label assignment removed from PDU. 

4 Datapath bound with remote MPLS service label assignment 

5 If not already performed 
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3.3.2 SETUP arrives on MS3 card entering the MPLS domain 
Figure 6 SETUP arrives on MS3 card entering the MPLS domain 




LgpNapConSvc::rcvSetupPdu_ v 



Is called 



Figure 6 on page 19, shows how, in the case when a SETUP arrives on the MS3 card 
entering the MPLS domain, the rcvSetupPdu_v method will be called on the 
LgpNapConSvc object associated with that connection. Figure 7 on page 20 show the 
message sequence within ATM networking on the MS 3 card and the new logic being 
added to support ATM over MPLS networking. 
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Figure 7 Message sequence: SETUP arrives on MS3 card entering MPSL domain 



|rcvSetupSwitchSide_T1 



^construct" 



|rcvSetupSwitchSiae_v 



NapAtmConMgr NapAtmCon ^ mC ^P NapCon LgpNapCon L gpNapConSv c 



|rcvKtgSetuprdu_v 



IconnReservelSw 1 | 



[connlreate Z 



1 



ireserveConnectionBw | 



|createConnecfion 



[Outgoing Setup (Incl. Cu end MFLS service label assign^] 



Note: 



1 MPLS service label assignment provided to ATM Networking along 
with MPLS transport LSP selection. 

2 Only if VPCI/VCI assignment authority .3 MPLS service label assignmel removed from PDU 



I 



LOGIC 

• Store the local MPLS label data received from ATM Core 
via ReserveBw on the LgpNapConSvc object 

IF (the data received is not NULL) 
THEN 

• add a GIT IE to the SETUP PDU Ptr containing this data 

ENDIF 
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3.3.3 SETUP arrives on MS3 card leaving the MPLS domain 
Figure 8 SETUP arrives on MS3 card leaving the MPLS domain 



VCC: 0.5 SETUP 




-tlTd 



SL:M 



VCC: 0.5 



SETUP 



MS3 CARD 



t 




LgpNapConSvc::rcvSetupLinkSide 
Is called 



VCC: 0.5 SETUP 



Figure 8 on page 2 1 , shows how, in the case when a SETUP arrives on the MS3 card 
entering the MPLS domain, the rcvSetupLinkSide method will be called on the 
LgpNapConSvc object associated with that connection. Figure 9 on page 22 show the 
message sequence within ATM networking on the MS3 card and the new logic being 
added to support ATM over MPLS networking. 



CDN Passport MS3/CE ATM Networking SD 



21 



Overall description 



Figure 9 Message sequence: SETUP arrives on MS3 card leaving the MPLS domain 



LgpSigLayer3lf L gpNapConSvc LgpNapCon 




LOGIC 

• Store the local MPLS label data received from ATM Core 
via ReserveBw on the LgpNapConSvc object 

IF (the incomming setupPduPtr contains the MPLS Data GIT IE) 
THEN 

• Store the remote MPLS label data contained in the GIT IE 
on the LgpNapConSvc object 

• remove the remote MPLS label data GIT IE from the 
SETUP PDU Ptr 

ENDIF 
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3.3.4 CONNECT arrives on MS3 card entering the MPLS domain 
Figure 10 CONNECT arrives on MS3 card entering the MPLS domain 



71; E 



$L:N 



VCC: 0.5 



CONNECT 



MS3 CARD 





LgpNapConSvc::rcvConnectPdu_v 
Is called 



VCC: 0.5 CONNECT 



Figure 10 on page 23, shows how, in the case when a SETUP arrives on the MS3 card 
entering the MPLS domain, the rcvConnectPduv method will be called on the 
LgpNapConSvc object associated with that connection. Figure 1 1 on page 24 show the 
message sequence within ATM networking on the MS3 card and the new logic being 
added to support ATM over MPLS networking. 
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Figure 11 Message sequence: CONNECT on MS3 card entering the MPLS domain 



NapAtmCon 

[rcvConnectSwitcliJide_v | 



NapCon LgpNapCon LgpNapConSvc 




LOGIC 

IF (the LgpNapConSvc object contains local MPLS label data) 
THEN 

• add a GIT IE to the CONNECT PDU Ptr containing this 
data 

ENDIF 



I 



LOGIC 

IF (the LgpNapConSvc object contains remote MPLS label data) 
THEN 

• Copy a reference to this data to the enablelnfo object 

ENDIF 

• Pass the enablelnfo object to ATM Core via a call to 
connEnable 
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3.3.5 CONNECT arrives on MS3 card leaving the MPLS domain 
Figure 12 CONNECT arrives on MS3 card leaving the MPLS domain 



VCC: 0.5 CONNECT 
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LgpNapConSvc::rcvConnectLinkSide 
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~tltg~ 



SL:N 



VCC: 0.5 



CONNECT 



s MS3 CARD 



Figure 12 on page 25, shows how, in the case when a SETUP arrives on the MS3 card 
entering the MPLS domain, the rcvConnectLinkSide method will be called on the 
LgpNapConSvc object associated with that connection. Figure 13 on page 26 show the 
message sequence within ATM networking on the MS3 card and the new logic being 
added to support ATM over MPLS networking. 



CDN Passport MS3/CE ATM Networking SD 



25 



Overall description 



Figure 13 Message sequence: CONNECT on MS3 card leaving the MPLS domain 




LOGIC 



IF (the incomming connectPduPtr contains the MPLS Data GIT IE) 
THEN 

• Store the remote MPLS label data in the GIT IE on the 
LgpNapConSvc object 

• Remove the remote MPLS label data GIT IE from the 
CONNECT PDU Ptr 

ENDIF 



LOGIC 

IF (the LgpNapConSvc object contains remote MPLS label data) 
THEN 

• Copy a reference to this data to the enablelnfo object 

ENDIF 

• Pass the enablelnfo object to ATM Core via a call to 
connEnable 
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4 Internal classes and data structures 

4.1 Classes and data structures 

There is only new class being introduced by this feature is the AtmConnXportData class 
described below. 

4.1.1 Class AtmConnXportData 

This class is used to store MPLS label data that is passed to and from ATM core. 

4.1.1.1 Class declaration 

class AtmConnXportData 
{ 

public : 
AtmConnXportData () ; 

AtmConnXportData (const void* data, Uint8 size) ; 

-AtmConnXportData () ; 

void* getXportData () const; 

void setXportData (const void* data, Uint8 size) ; 
Uint8 getXportDataSize () const; 
private : 

void* xportData_mp; 
Uint8 xportDataSize_m; 

}; 
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4.1.2 Class NapGenldTransIe 

The following are new methods which need to be created on the NapGenldTransIe class. 
They are used to set and get MPLS data information from the GIT IE. 

4.1.2.1 NapGenldTransIe: :setXportData_v(...) 

This new method in take the data contained in the AtmConnXportData object and copies it 
to the MPLS data GIT IE. 

• Inputs 

AtmConnXportData* connXportData ; 

• Outputs 

VOID 

4.1.3 Class NapGenldTransIe 

4.1.3.1 NapGenldTransIe: :getXportData(...) 

This new method populates the AtmConnXportData with the data contained in the MPLS 
data GIT IE. 

• Inputs 

AtmConnXportData* connXportData ; 

• Outputs 

Bool 

4.1.4 Class NapPduPtr 

The following is a new method which needs to be created on the NapPduPtr as part of this 
feature. 

4.1.4.1 NapPduPtr::getXportGenIdTransIe(...) 

This new method will retreive the MPLS data GIT IE and return true if one exists. 
Otherwise it returns false. 

• Inputs 

NapGenldTransIe^ genldTransIe ; 

• Outputs 
Bool 
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5 File organization 



Table 1 MODIFIED files 



File Name 


File Description 


atmApiDefs.h 


All API related definitions, data structures and types which are used by 
applications when using the functional API 


napPdus.h 


Modifications to the NapGenldTransle Class and the NapPduPtr Class 


napPdus.cc 


Modifications to the NapGenldTransle Class and the NapPduPtr Class 


IgpNapCon.h 


Add new data pointers to the SavedSetuplnfo Struct on the 
LgpNapCon Class 


IgpNapCon.cc 


Modifications to configAndEnableVcc 


IgpNapConSvc.cc 


Modify the rcvSetup and rcvConnect methods 
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Appendix B Rejected alternatives 

B.l Design number one 

B.1.1 Advantages 

B.1.2 Disadvantages 

B.1.3 Reasons for rejection 
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The proposed Nortel standards contribution to be submitted to the April ATM Forum mtg is attached m 
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This invention provides a mechanism to allow the call establishment of ATM connections over a lower layer non-ATM 
connection-oriented media through the utilization of ATM signaling protocols to exchange lower layer transfer plane 
information. 
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A typical use of this invention is to allow the establishment of ATM connections over an MPLS transport media using ATM 
signaling to convey MPLS transfer plane information. 

ATM Networking over MPLS design documentation is attached. 
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Through the use of ATM signaling protocols, lower layer connections can be established with ATM call establishment 
procedures to allow a faster and more efficient mechanism for tunneling ATM on-demand connections through an MPLS 
network. 

Potential solutions involve the coordination of MPLS and ATM control planes, but the coordination of 2 separate control planes 
and signaling protocols are more complex and less efficient than the proposal discussed in this invention disclosure. 

Currently there are no call control procedures for the establishment and clearing of ATM on-demand connections over MPLS. 
This invention proposes a solution to the establishment and clearing of ATM connections over an MPLS network. The invention 
presented can also be extended to incorporate ATM call control procedures over a connection-oriented media. 

An MPLS network consists of MPLS switches serving as Label Edge Routers (LERs) and Label Switched Routers (LSRs) and 
provide connection services for the establishment of MPLS connections. To allow ATM connections to traverse an MPLS 
network, ATM connection information needs to be exchanged between its call control peers. In ATM networks, ATM signaling 
protocols are used to exchange ATM connection context between its call control peers. To allow on-demand ATM connection 
services an ATM signaling channel needs to be configured through an MPLS 'transport* connection between call control peers. 
Once established, this invention allows ATM connections to be established and cleared within the same MPLS 'transport' 
connection using MPLS label stacking to identify individual ATM connections as MPLS 'service' connections. This mechanism 
allows ATM connections to be established, maintained and cleared across an MPLS network without intervention from MPLS 
signaling protocols (e.g. RSVP, CR-LDP). 

To achieve this, the exchange of transfer plane information (e.g. MPLS label reservations) for individual MPLS 'service' 
connections associated with each individual ATM connection is conveyed within existing ATM signaling PDUs (i.e. SETUP 
and CONNECT PDUs). Once MPLS transfer plane information is exchanged between ATM signaling peers the MPLS 'service' 
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